次世代 Web カンファレンス ：マイクロサービス
避けては通れない（@fujiwara）
自然とやってればマイクロサービスになるでしょう（@tokuhirom）
大きいシステムを作っていると分散システムとして作ることがになる、そうするとマイクロサービスに一致する部分が多い。そういう分散システムがウェブにやってきた物（@tagomoris）
トラブル・分散トレーシング
どこでトラブルが起きているか分からなくなってくる（@tagomoris）
トレースはライブラリーを入れて取っている（@fujiwara）
分割をいっぱいしている所には入れられていない。Redisとかに入れてる
プロファイラーとして使ってる
「複数のサービスをまたいでトレースできるのが主眼」と捉えている人が多そうだが、そういう使い方をしてる人は多くないのでは？（@tokuhirom）
LINEとかアクセス多すぎてトレースを追ってくのが難しい
一台のサービスでプロファイリングしてるのが多い
トレースの目的
１レコード単位でサービスまたがってトレースしようと思うと、レコード数が爆発する（@tagomoris）
「何かあった時のトレース」の目的では分散トレースは使えなさそう
が、レアケースのトレースが必要になることがある
普段はサンプリング、エラーの時だけ確実に痕跡を残す
サービスを経由する途中でデータがおかしい状態になってしまうことがある。そのトレースをしたい（@tagomoris）
問題があった時の調べ方
あちこちにデバッグログを吐きまくるしかない・・・？（@tagomoris）
データとしてログは貯めてはいるから、それを後から分析することはできる（@tokuhirom）
これからうまくやる方法ないのか？（@tagomoris）
量の問題はあるが・・・
単に「頑張る」しかないのか・・・？
リクエスト単位でIDを発行して、各サービスのログでgrep、とか（@fujiwara）
LINEもそうなってる（@tokuhirom）
実際に検索できるようにはなってない
ログの粒度は各開発者に任される（@tagomoris）
調べる時のクオリティの担保が難しい
障害
どう再現させるか
どう障害対応を作り込むか
それぞれのサービスで障害対応ポリシーを作るとして
ガバガバのサービスが一個あると大変
サービス出す前には、コンポーネントを落としてみてチェックする（@fujiwara）
サービスイン後は個別になる（@fujiwara）
Chaos Engineeringになるとは思う
そのためにはリトライを全体で作り込んでいないといけない
今は気を配ってない
リトライもいいが、リトライしまくった結果死ぬことがあるので難しい（@tokuhirom）
Chaos Engineeringは新入社員教育のためにやってる
リトライがうまくいっても、レイテンシーが増えることは織り込まないといけない（@tagomoris）
B2Bになると「1%ならいいだろう」みたいのが許されなくなる。考えることが増える
ログのロストとかはお客さんが損をするので絶対だめ（@tokuhirom）
Chaos Engineeringはお客さんが損しないはずなのであり
Netflixは月額課金だから落ちててもあんまり関係ない
「国外ビッグプレイヤーがやってるから無反省に導入したがる」のはよくない
やっとかないと、障害が起きた時に大騒ぎするまでは直せなくなる（@fujiwara）
それと普段ちょっと障害が起きているのとどっちがいいのか
B2Bは顧客にそれを強いれるかというとそうではない
Canaryデプロイ
Chaos Engineeringと同じジレンマがある
障害を意図していないのが違う
やらないで爆発するよりはやった方がいい（@fujiwara）
あまり考えないでできるようになっているのが大事（@fujiwara）
「今回はやってみよう」で手軽にできるように作り込めてるならいい
一般的な気をつける点
ログを見ておく
モニタリングのステータスを見ておく
デプロイ前に影響しそうなリクエストを見ておいてその影響を見ておく
マイクロサービスになったからといって変わる訳ではない（@tagomoris）
「自分のサービスが大丈夫だから全体が大丈夫だった」と作るべきなのが教科書的な正解ではある
インフラ
インフラストラクチャーや実装がそこを救える可能性があるのか
課題「サービスメッシュのレイヤーを、それを実現するソフトウェアを使うか」
consulで名前解決をして見るべきログを特定しているアクセスのところは各クライアント（MySQL、Redis・・・）が頑張ってる（@fujiwara）
Envoyを入れる話が出てる
リトライ、タイムアウト、DNSキャッシュのTTL、サーキットブレイカーがサービスメッシュのレイヤーで対応されていればサービスの実装によらず解決できる（@tagomoris）
これが整備されればChaos Engineeringができるようになる
どの段階でサービスメッシュ入れるか？
入れるの当たり前になればいい（@fujiwara）
アプリケーション作る側が楽になる
リトライの処理とか考えるのめんどい
バックエンドを自分たちで作り込むのか？
Firebaseみたいなのがあればいいのではないか（@fujiwara）
インフラは良くなる（@fujiwara）
データ構造が難しい。それを考える人が必要になる（ @fujiwara）
サーバー間やクライアントからの通信
言語がバラバラになるのでスキーマなしでやり取りするのは無理（@fujiwara）
protbuf
「MySQLを直接叩かずgRPCでくるむ」というやり方がある（@fujiwara）
クエリー投げる側が考えることが減る
そうするとクライアントからもgRPCで通信するようになる
言語によってライブラリーの安定性が違う
当初JSONで作っても利用者が増えてパフォーマンスがきつくなることがある（@tokuhirom）
ThriftとかgRPCになる
Kafkaとかの前にgRPCのラッパーレイヤーを一々作るのはめんどくさい（@tagomoris）
直接Kafkaに繋いでる（@tokuhirom）
PerlはライブラリーがよくないのでJavaでプロクシーしている
DC内でhttpsにするか
sじゃないと辛いがsにするのは証明書がめんどい（@fujiwara）
内部向けの発行するやつを作らないといけない
言語
「マイクロサービスで言語が色々使える」はあるが、JSONは大体の言語でいけるが、Apache ArrowとかgRPCの場合ライブラリーの質が悪い言語がある（@tokuhirom）
AmazonやGoogleがサポートしている言語だけを使うのがいい
大方針はJavaを使う。速度の出ない言語は使わない
最近はgoが多い（@fujiwara）
型のある言語で書かないとめんどくさいながれ（@fujiwara）
エディターサポートがよくなってきてるから型がめんどくさくなってない
チームや会社でgoに寄せてく認識があってそうしているのか？（@tagomoris）
そう。Perlだと人が採用できない。その時に、なんでもいいがGoにした（@fujiwara）
マイクロサービスになったら各サービスで好きな言語を使える、という話があったが実際には？
ある。一部だけScalaとかKotolin（@tokuhirom）
JVMの上で動くので、クライアントライブラリーの品質は一緒なので問題ない
Haskelとかひまわりになると厳しい。仲間が二、三人いないとずっとメンテナンスが難しい
韓国やベトナムに持って行った時にそっちで開発者がいないと厳しい
監視の言語依存性はPrometheusは各言語で触れるようになっていてやりやすくなってる（@tokuhirom）
Goは監視で困ることはあまりない（@fujiwara）
内部状態をエクスポーズするライブラリーがあるので
サービスをいっぱい作る時、言語が揃ってる方が、立ち上げの部分共通化できて効率がいいはずだが？（@tagomoris）
相手のサービスのコードが読めないと効率は悪い（@tokuhirom）
Javaの人はPerlを読めないがPerlの人はJavaを読める。Perlが損、となっちゃった
最初Ruby多かったがトラフィック増えてくるとJavaになってきた（@tagomoris）
モノリスだとビッグジャンプになるので話題にもなる
マイクロサービスだとサービス単位で置き換えていけるのでいい
そういう移行が頻繁に起こるのがいいのかは別の話だが
ある程度枯れた言語にしておくといい -> Java（@tokuhirom）
「人数が多くなるとマイクロサービスにするのが当たり前」という雰囲気があるが？
でかいリポジトリーはメンテが大変（@tokuhirom）
それ以外は分けていく
「一つの大きいチーム」はマネジメントもコミュニケーションも大変
ピザ二枚を守ろうとするとマイクロサービスにはなる。それ以外にマイクロサービス化のきっかけはあるのか（@tagomoris）
古いサービスを分けようとしている（@fujiwara）
新しいサービス出るときやマイグレーションの時に分ける機運になる（@fujiwara）
一コンポーネントを担当する人数
エンジニアで四人だときつい（@tagomoris）
四人いれば大丈夫（@fujiwara）
物による
少ないと技術が伝承されないという問題もある（@fujiwara）
一人で回るとしても一人にやらせるのはよくない（@tokuhirom）
地理的要因
チームは同じ地域で作るのが基本（@tokuhirom）
コンポーネントごとにチームが分かれて、コンポーネントが地域で分かれているので
同じチームが各地に分かれてる（@tagomoris）
会話が難しい。確認に一日かかるとか
チーム人数が少ないと一拠点に一人しかいなかったりして、教育に問題が出る
監視が分担できるのはいい
働いている人のところに人が来るとそのコンポーネントを触る
ウェブのサーバーサイド
マネージドサービスがなんでもやってくれるようになって、一人がやれる範囲が増えていっている（@fujiwara）
「これだけしかやりません」という人は辛くなっていく
広くやっていくかピンポイントで本当に深くやるか決めないといけない
昔は一人でまとめてやることが多かったが、最近は一つのことをずっとやる（Kafkaのワーカーを半年間書くなど）（@tokuhirom）
やればいいというだけの人が揃ってるから、あまり話すことがないのかな